Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9703/000020_owner-urn-ietf _Tue Mar 11 10:02:18 1997.msg

Internet Message Format | 1997-04-01 | 4KB

Received: (from daemon@localhost)
    by services.bunyip.com (8.8.5/8.8.5) id KAA13941
    for urn-ietf-out; Tue, 11 Mar 1997 10:02:18 -0500 (EST)
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1])
    by services.bunyip.com (8.8.5/8.8.5) with SMTP id KAA13914
    for <[e-mail]>; Tue, 11 Mar 1997 10:02:14 -0500 (EST)
Received: from [132.146.5.4] by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA13173  (mail destined for [e-mail]); Tue, 11 Mar 97 10:02:02 -0500
Received: from ferao.jungle.bt.co.uk by mailhub.axion.bt.co.uk with SMTP (PP); Tue, 11 Mar 1997 14:57:00 +0000
Received: from phao.jungle.bt.co.uk by ferao.jungle.bt.co.uk (Jungle-SMTP-01) ID AA00312; Tue, 11 Mar 1997 14:52:33 GMT
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 11 Mar 1997 14:59:39 +0000
To: [e-mail]
From: Bob Briscoe <[e-mail]>
Subject: [URN] URNs grandfathering certain Object or Interface References
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
Reply-To: Bob Briscoe <[e-mail]>
Errors-To: [e-mail]

Apologies if this has already covered - I've not being reading the URN list
too carefully recently, but a scan of the archive and the latest NAPTR
draft makes me think I have identified a new problem.

The NAPTR proposal has a regexp/replacement field based on sed which is a
text based transformation.

DCE universally unique id's (UUIDs) used by Microsoft's COM (as well as
DCE) and CORBA/2 Interoperable Object References (IORs) are typically
generated to include a references to the service for resolving them but
they can both be stringified to end up being a string of hex characters.
Proposals have been put forward to introduce these as new URL schemes.

Refer to:
The "clsid:" URL Scheme, Charlie Kindel, Microsoft Corporation, Feb 28 1996
Draft, <URL:http://www.w3.org/pub/WWW/Addressing/clsid-scheme>

CORBA 2.0, Universal Network Objects, PTC/96-08-04, Object Management
Group, Inc. July 1996 <URL:http://www.omg.org/corba/corbiiop.htm> [Section
10.6.5 Stringified Object References]

You end up with URLs like:
clsid:EFF6744C-7143-11cf-A51B-080036F12502
or
IOR:000000000000001b9444c3a48656c6c6f576f726c642f476f6f644461793a312e3000000
00000010000000000000044000100000000000e3133302e31303a22e3137362e3900d7820000
002800504d43000000010000001448656c6c6f576f726c643a3a476f6f644461790000000002
cc52247e

I don't know to much about UUIDS but I know that IORs are intended to be
semi-resolvable outside the domain in which their id has true context, at
least to the extent that the services they rely on for resolution, and the
originating domain can be identified.

The problem is that some COM/CORBA based systems can interpret these
strings of hex digits to extract the machine/port etc. which hosts the
object they need for resolution, but the algorithm isn't a simple textual
transformation.

How might NAPTR cope with this without just resorting to a replacement
string and lumping the whole problem on one global resolver for the whole
scheme leading to a horrible bottleneck?

Alternatively, given that Object systems have their own location
transparency schemes, might URN not be relevant here (then we'd have to
rename them FURNs (Fairly Universal Resource Names)? I would have thought
that if URN could be made relevant, it should be.

Apologies in advance for anyone who wants me to explain these schemes in
any more depth - my knowledge is fairly sketchy.

Bob
____________________________________________________________________________
Bob Briscoe         http://www.labs.bt.com/people/briscorj/index.htm